Integrate with latest ECMA-262 import attributes #116
Conversation
nicolo-ribaudo
left a comment
nicolo-ribaudo
left a comment
There was a problem hiding this comment.
This looks correct from the point of view of properly integrating with ECMA-262.
I don't love the proposed "syntax", but I don't have better suggestions.
|
@guybedford How confident are we that the import attribute syntax won't grow beyond the capabilities of URL query params? I'm a little mixed on this, because while it'd be nice to not have a semantic gap here, taking on fully-correct URL parsing is challenging. AFAIK, SpiderMonkey doesn't have a URL parser in it. |
|
There are at least some desires to start supporting booleans in import attributes other than strings. At some point there was some discussion about allowing arbitrary JSON (for the builtins option of WebAssembly.compile when importing Wasm from JS), but we ended up with a comma-separated string.
Resolving module specifiers when dealing with JS already requires URL parsing, because they are URLs. SpiderMonkey calls into Geko for it (in Firefox). And Geko has more than one URL parser :) |
The import attributes specification is now part of ECMA-262. This rebases the spec to handle the new module request record and import attribute record functionality in module resolution.
In addition, I've also integrated a simple proposal for import attributes integration along the lines discussed in #42.
The design is to allow a
?...querystring on the export name to indicate the attributes, using standard URL query param semantics and referencing the URL spec for this exactly. This then fully encodes the import attributes grammar.Effectively then,
"./foo.bin" "default?type=bytes"can be used to import an immutable array buffer for arbitrary external data.Supporting bytes, CSS and JSON imports natively for Wasm can be simply implemented this way.
This does change the meaning of
?in export names - but these are not currently commonly used in JS (I don't think I've ever seen aimport { "?" as foo } from 'bar'). So it seems like this doesn't conflict with other uses since we have the source phase opt-out for other interpretations anyway not the instance phase. But we could add additional disambiguation by prefixing the export name withwasm-js:orwasm:if we wanted to have a stricter scheme here. Perhapswasm-js://default/with?type=bytes, although it seems like it might be overkill too.